In a computer application, a user can usually hold down a button causing the button press action to effectively repeat until the user releases it. For example, holding down an arrow (cursor) keyboard key in a word processor application continues to move the cursor within the document (until an ending point is reached) without the user having to continually actuate and release that arrow button. A spreadsheet provides the same repeat behavior whether moving among cells or moving the cursor within the text of a cell.
Continuing with the above application examples, when the user holds down the arrow key, the cursor jumps once immediately, delays a little while, and then starts continuously repeating. The small delay results from the application ignoring the repeating key command events for a little while to give the user time to release the button and thereby avoid starting the continuous repeat unless desired.
Another typical repeat feature is that the most recent button selected is the only one that can repeat. For example, if a user holds down the right arrow keyboard key and then holds down the left arrow keyboard key (without releasing the right arrow key), the cursor movement to the right stops and instead starts going left. Thereafter, If the user releases the left arrow key (still without having released the right arrow key), the cursor movement stops and does not start going right again.
The above button repeating operations are typical standard behavior in many applications. While this works reasonably well in applications that in general have a main user interface (e.g., for typing in text or moving among spreadsheet cells) plus a few drop-down menus, it is relatively limiting to have the same behavior apply everywhere in an application. Indeed, a more complex user interface may have many menus, some with a few selections and others with hundreds or even thousands of selections available per menu. It is not flexible for a developer to have to use the same repeat pattern throughout a user interface.